perf(adjoint,#17315): gate 100% REST + reviewThreads batchees par alias + compteur publie - #19966

Grain: MED/refactor — lane myia-po-2026:CoursIA — prev: DEEP/notebook-python #19962

Cible

See #17315 — le quota GraphQL partagé par la flotte, dont le gate de prévalidation et l'organe B.0 sont les deux consommateurs. Incident mesuré le 2026-09-21 : une passe de 200 appels de gate a rendu 110 rc=2 consécutifs et laissé le gate mort une heure pour tout le monde.

Cette PR traite les leviers 1-2 et 3 côté gate, plus le critère du compteur. Elle ne traite pas le levier 4 (partition des buckets), qui exige un arbitrage user.

Les trois volets

1. _pr_metadata en REST pur

gh pr view --json (bucket GraphQL) est remplacé par repos/.../pulls/N. Les clés rendues gardent la forme exacte que gh pr view --json produisait — l'identité du bracket before/after et les empreintes de surface restent byte-compatibles avec les dossiers déjà estampés.

Le champ statusCheckRollup disparaît de l'organe. Sa dernière raison d'être était le chemin de compatibilité retiré au volet 2.

Le bracket de stabilité couvre désormais les seuls champs scalaires de la PR, et l'organe le dit dans son commentaire plutôt que de laisser croire qu'un changement de conclusion de check le déclenche : les check-runs sont lus dans le bracket mais indexés sur la tête lue avant lui, donc une poussée pendant la lecture déplace headRefOid, les deux lectures divergent et le snapshot est refusé (fail-closed) au lieu d'apparier les check-runs de l'ancienne tête avec la nouvelle.

2. legacy_surfaces_fingerprint retiré

Sa docstring énonçait sa propre condition de mort — « drop this function when no open dossier carries a legacy stamp ». Ses deux porteurs sont mergés (vérifié firsthand : #16950 MERGED 2026-09-22T02:59:58Z, #16891 MERGED 2026-09-22T20:17:55Z), et son dernier consommateur GraphQL part avec lui.

Le résidu dégrade fail-closed vers l'unique geste de récupération, un re-stamp mécanique --template, que le message de refus nommait déjà.

3. reviewThreads batchées par alias

Une opération GraphQL pour N PRs (lots de 8), au lieu d'une par PR :

query($owner:String!,$repo:String!,$p0:Int!,$p1:Int!,...){
  p0: repository(owner:$owner,name:$repo){pullRequest(number:$p0){reviewThreads(first:100){...}}}
  p1: repository(owner:$owner,name:$repo){pullRequest(number:$p1){reviewThreads(first:100){...}}}
}

Une PR dont les threads débordent la première page repart en pagination par curseur — pour elle seule. Le refus >100 commentaires inline (garde-fou qui empêche une page tronquée de se lire comme un thread complet) survit au batching.

4. Le coût est publié

Compteur API_USAGE incrémenté dans le funnel unique gh_json, exposé en clé api_usage du --json et en ligne stderr ; stdout reste le verdict que les appelants parsent.

Mesure avant / après

Compteur injecté sur le funnel, même PR (#19943), load_snapshot :

Invocation complète --json après la PR, sur #19943 (sortie réelle) :

API usage: 6 REST, 1 GraphQL operation(s)
{"pr": 19943, "ready": false, "verdict": "BLOCKED", ..., "blocking_fields": ["checks"],
 "api_usage": {"rest": 6, "graphql": 1}}

En passe de masse, la part threads passe de N opérations à ceil(N/8) ; la part structures reste à 1 opération par PR.

Un piège d'instrument rencontré, et pourquoi le run live est la seule preuve

La réponse d'une requête à alias imbrique la connexion sous pullRequest : c'est data["data"]["pN"]["pullRequest"]["reviewThreads"]. Ma première version lisait ["pN"]["reviewThreads"] et levait un KeyError.

Le premier jet est passé 165/165. Le fixture de test avait été écrit depuis la même lecture erronée que le code — il reproduisait fidèlement le bug, et deux tests verts certifiaient un chemin mort. C'est le run live sur #19943 (UNKNOWN: 'reviewThreads' en 1,4 s) qui l'a trouvé, puis la requête rejouée seule pour lire la forme réelle de la réponse.

Le commentaire du code porte la mesure et le fixture de test encode désormais la forme réelle : une régression vers l'ancienne lecture lève un KeyError et rougit.

Critères d'acceptation de #17315

Les critères n'étant pas tous couverts, cette PR dit See #17315, pas Closes.

Collision et doublon signalés

#19926 (lane myia-ai-01:CoursIA-2, DEEP/tooling, ouverte, CONFLICTING/DIRTY) touche le même fichier. Vérification faite : son sujet (#19869) est déjà sur main via #19892 (3da0412cde — find_previous_blocked_same_head, pré-remplissage supersedes/supersedes-why, tests présents). C'est un doublon périmé, d'où le conflit. Le signalement [INFO] candidate-delivered est posté sur #19926 avec sa preuve ; la fermeture revient au coordinateur ou à l'adjoint, pas à une lane worker.

Cette PR se base sur main courant (qui porte #19892) : le conflit est donc du côté du doublon, pas du côté de cette PR.

Validation

• py -3.13 -m pytest scripts/tests/test_check_adjoint_prevalidation.py -q → 165 passed
• suites des importateurs directs (check_closure_dossier, check_run_state, merge_ready, post_dossier, frozen_campaigns, sweep_stale_pr_branches, update_stale_pr_branches, gh_identity) → 262 passed
• balayage adjacent scripts/tests/ (-k "adjoint or prevalidation or gate or unaddressed") → 1366 passed, 2 skipped
• run live de l'organe sur feat(19920,#19898): ANALYSE-07 Percolation-Critique -- pli 3 Origami (tranches A+B) #19943 : verdict lu correctement (dossier de la lane CoursIA-3), api_usage publié

Tests ajoutés : comptage REST/GraphQL par bucket · publication api_usage en --json + stderr · une opération pour N PRs · découpage au-delà de la taille de lot · déduplication · repli en pagination pour la seule PR qui déborde · refus >100 inline préservé · une PR seule = une opération.

Fichiers

scripts/check_adjoint_prevalidation.py
scripts/tests/test_check_adjoint_prevalidation.py

🤖 Generated with Claude Code